A service automation platform Provider is an organization that sells subscriptions to a variety of software services (the “Software Services”) to its customers. Commonly, these customers are small or medium-sized organizations as well as individuals. The service automation platform Provider may have its own computing capabilities. The service automation platform Provider can also sell subscription for Software Services involving a computer data center which is located in its own facilities, as well as cloud based software-as-a-service (SaaS) involving computer data centers located at facilities of developers of the services or other remote locations.
The service providers are various software companies. Their function is to develop, support, execute, and sell services (or subscriptions to services). For example, vendors of SaaS, like dropbox.com, office365.com, to name a few non-liming examples, may be considered as service providers. For each service, the service providers provides an application programming interface (API), comprised of a set of predefined classes, procedures, functions, structures, and constants for the use of external software products.
When a service automation platform Provider desires to offer to its customers integrated Software Services of a plurality of service providers, the service automation platform Provider develops a service delivery platform that integrates the desired Software Services. In at least one embodiment of the present disclosure, the API is used to integrate the service providers's services with the service automation platform provided by the service automation platform Provider.
When integrating various Software Services, it is desirable to ensure that authentication and access controls are in place for users of the integrated Software Services. In at least one embodiment of the present disclosure, a single sign-on (SSO) technology is used. With SSO, a user presents authentication credentials to a service once using one set of login credentials (e.g., name and password, to name just one non-limiting example), and is subsequently allowed to access Software Services.
Referring now to FIG. 1, there is shown a conventional system for integration and management of SSO, generally indicated at 100. The system 100 comprises a first service provider 110, a second service provider 111, a service provider SSO API 115, a service provider provisional API 117, a tenant 120, a service automation platform 130 and a user interface 140 therein, a shared identity provider (IDP) 150, a shared IDP user storage 160, a shared IDP credentials storage 170, a user 180, a service provider plug-in 175, a service provider plug-in user interface 185, a service provider service provisioning module 190, and a service provider user data storage 195. It will be appreciated that the conventional system for integration and management of SSO may include a plurality of service provider plug-ins (e.g. a second service provider plug-in 176).
Tenant 120 may represent a client of the service automation platform 130. Tenant 120 can be purchases of services from the service automation platform 130. Tenant 120 may subscribe to at least one of a plurality of SSO-based software services offered by service providers 110 and 111. For example, tenant 120 may use the user interface 140 (e.g., a graphical user interface) of the service automation platform 130. The user interface 140 operates to request a service provider that corresponds to the each of the service providers 110 and 111. For example, the user interface 140 may operate to request service provider plug-in 175 for provisioning of a subscription to the service provider 110. The service automation platform 130 is operably connected with the service provider plug-in 175, via the service automation platform 130, for technical integration of the software service offered by the service provider 110. It will be appreciated that a particular plug-in is usually provided for a particular service, e.g. plug-in 175 is designed for the service provider 110 and plug-in 176 is respectively designed for the service provider 111. It will be further appreciated that a group of service providers may use the same service provider plug-in.
The system 100 requests federation service provisioning using the service provider provisional API 117, that is defined by the service provider 110. When a user 180 desires to access a plurality of service from the each of the service provider 110 and 111, the user 180 is granted the ability to use the same set of credentials across the plurality of services from the each of the service provider 110 and 111. In the conventional system for integration and management of SSO, authentication may take place in one single domain (i.e. for example, with a single service provider 110), and other security realms that trust this primary domain can reuse the authentication and trust the authenticity of the identity established. This results in what is called a federation. Federation provisioning comprises provisioning of a user attribute schema (not shown) and user Attributes (not shown) which are stored in shared IDP user storage 160, and service provider plug-in user storage 195. The user attribute schema comprises rules of attribute packaging. The user attribute schema may be different for each of the plurality of service providers 110 and 111. The tenant 120 further uses the user attribute schema to transmit data concerning its users, as well as data which are expected to be generated in the process of provisioning. This data may include various types of user attributes, such as, for example, a username, email address, address, subscription id, tenant id, and zip-code. The user attributes may further comprise such data such as, for example, username, mail, address and zip-code, which may be entered by the tenant 120. It will be further appreciated that the user attributes may also include, such as, for example, subscription id, and tenant id, which may be generated in the process of provisioning a user 180 with access to service provider 110 and 111. After any change in the user attributes the service provisioning module 190 updates the user data storage 160, and service provider plug-in user storage 195, and synchronizes them. It will be appreciated that the second service provider plug-in 176 may be used to create a subscription to the second service provider 1
In at least one embodiment of the conventional art, in order to access the service provider 110 (or 111), a user 180 opens a link, such as, for example, a URL, to the plurality of software services provided by the service provider 110 (or 111) in the process of provisioning. The link directs user 180 to shared IDP 150. The user 180 presents his/her user credentials, such as for example, a user name and password combination, to the shared IDP 150. The shared IDP 150 retrieves user attributes and packages it into an attribute statement according to a provisioned attribute schema and redirects the user 180 to the service provider 110 via the service provider SSO API 115, using a signed authentication token. The shared IDP 150 forms the SSO token using the user attributes and the user attribute schema from shared IDP user storage 160, and using credentials 170, which are trusted by the service provider 110. The shared IDP 150 then redirects the user 180 by a standard SSO request with an embedded SSO token. Thus, the user 180 is granted access to the service provider 110 without entering any further credentials.
A conventional identity provider used by service automation platform 130 has mainly two variants of SSO deployments or their combination: 1) a Shared Identity Provider model wherein a single dedicated identity provider server with all service providers' (e.g. service provider 110 and 11)1) data provided from all tenants 120, where all tenants 120 reuse the contract between the service provider 110 (or 111) and the service automation platform 130; and 2) a Private Identity Provider model wherein there is an auto-allocated identity provider per tenant account or per subscription, where all tenants 120 have a separate contract between the service provider 110 (or 111) and the tenant 120, and the service automation platform 130 is a third party. The Private Identity Provider model makes the same list of actions and connections with the each of the service provider plug-ins 175 and 176, the service automation platform 130 and with service providers 110 and 111 as in the Shared Identity Provider model.
The conventional embodiment has a number of shortcomings. First, there are contract issues that need to be addressed. In the scenario with shared identity provider 150, a service provider 110 (or 111) should trust a single identity provider of the service automation platform 130. However, sometimes the service provider 110 cannot trust certain installations, such as, for example, when the service automation platform 130 is new and not well established as being credible. Furthermore, the service automation platform 130 comprises a third party relationship between a tenant 120 and the service provider 110 (or 111), and, if the service provider 110 trusts any tenant 120 of the service automation platform 130, it has to trust all tenants of this service automation platform 130. A private identity provider may be used, but it forces tenants to configure their own identity provider and to make separate contracts with the service provider 110 (or 111).
A second issue arises when a shared identity provider 150 or private identity provider keeps user attribute. The user attributes are stored in service provider plug-in's user storage 195 and can be changed by a service provider 110. The user attributes are responsible for compatibility between the tenant 120 and the service provider 110 (or 111). This means that the user attributes must be synchronized every time between service provider 110, service provider plug-in 175 and shared IDP 150. If an issue arises, the service automation platform 130 is focal point as all interactions go through the service automation platform 130. This issue is more problematic in the Shared Identity Provider model because this model may include a more complex configuration for all of the service providers operating at the same time.
A third issue is technical costs with syncing; as the user attributes can be changed, and the user attribute schema can be changed on the service provider 110, and the service provider plug-in 175 is responsible for syncing these values to the corresponding identity provider (e.g. Shared Identity Provider 150). This may be problematic because syncing of the entire set of the user attributes and user attribute schema can lead to longer sync times and additional storage with duplicated data.
A fourth issue is the technical difficulties arising around the complexity of the API. A complex API is required for provisioning the Identity Provider, which supports the syncing feature. Also, this API must have security requirements to prevent malicious User Attribute changes and theft of authentication data.
Lastly, several identity providers are managed within the subscriptions. Some services require several identity providers in a single subscription. For example, MICROSOFT® Corporation requires a separate identity provider for every active directory domain. Therefore, it is impossible to consider all possible configurations of the identity providers for all of the service providers 110 and 111.
Accordingly, it is desired to have an improved multi-tenant SSO system, which overcomes the shortcomings of the conventional SSO system, by having a capacity for plug-ins to create a number of the virtual identity providers.